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Les 


Introduction 


Security Assertion Markup Language (SAML) 2.0 [OASIS-SAMLv2-CORE] is 
a set of specifications that provide various means for a user to be 
identified to a Relying Party (RP) through the exchange of (typically 
signed) assertions issued by an Identity Provider (IdP). It includes 
a number of protocols, protocol bindings [OASIS-SAMLv2-BIND], and 
interoperability profiles [OASIS-SAMLv2-PROF] designed for different 
use cases. 


The Simple Authentication and Security Layer (SASL) [RFC4422] is a 
generalized mechanism for identifying and authenticating a user and 
for optionally negotiating a security layer for subsequent protocol 
interactions. SASL is used by application protocols like IMAP 
[RFC3501], the Post Office Protocol (POP) [RFC1939], and the 
Extensible Message and Presence Protocol (XMPP) [RFC6120]. The 
effect is to make modular authentication, so that newer 
authentication mechanisms can be added as needed. This memo 
specifies just such a mechanism. 


The Generic Security Service Application Program Interface (GSS-API) 
[RFC2743] provides a framework for applications to support multiple 
authentication mechanisms through a unified programming interface. 
This document defines a pure SASL mechanism for SAML, but it conforms 
to the new bridge between SASL and the GSS-API called GS2 [RFC5801]. 
This means that this document defines both a SASL mechanism and a 
GSS-API mechanism. The GSS-API interface is OPTIONAL for SASL 
implementers, and the GSS-API considerations can be avoided in 
environments that use SASL directly without GSS-API. 


As currently envisioned, this mechanism enables interworking between 
SASL and SAML in order to assert the identity of the user and other 
attributes to RPs. As such, while servers (as RPs) will advertise 
SASL mechanisms (including SAML), clients will select the SAML SASL 
mechanism as their SASL mechanism of choice. 


The SAML mechanism described in this memo aims to reuse the Web 
Browser Single Sign-On (SSO) profile defined in Section 4.1 of the 
SAML 2.0 profiles specification [OASIS-SAMLv2-PROF] to the maximum 
extent and therefore does not establish a separate authentication, 
integrity, and confidentiality mechanism. The mechanism assumes that 
a security layer, such as Transport Layer Security (TLS) [RFC5246], 
will continue to be used. This specification is appropriate for use 
when a browser instance is available. In the absence of a browser 
instance, SAML profiles that don’t require a browser, such as the 
Enhanced Client or Proxy profile (as defined in Section 4.2 of 
[OASIS-SAMLv2-PROF], may be used, but that is outside the scope of 
this specification. 
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Figure 1 describes the interworking between SAML and SASL: this 
document requires enhancements to the RP (the SASL server) and to the 
client, as the two SASL communication end points, but no changes to 
the SAML IdP are necessary. To accomplish this goal, some indirect 
messaging is tunneled within SASL, and some use of external methods 


is made. 
+----------- + 
> Relying 
/ | Party 
// | | 
// prina + 
SAML/ // ^ 
HTTPS // +--|--+ 
// S 
; s| a 
// a | mi | 
// s | L| | 
// BA A | 
// | | | 
</ +--|--+ 
+------------ + v 
| | po - 
| SAML | HTTPS | | 
| Identity |<--------------- >| Client | 
| Provider | | | 
+------------ + +---------- + 


Figure 1: Interworking Architecture 
1.1. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


The reader is assumed to be familiar with the terms used in the 
SAML 2.0 core specification [OASIS-SAMLv2-CORE]. 


1.2. Applicability 
Because this mechanism transports information that should not be 


controlled by an attacker, the SAML mechanism MUST only be used over 
channels protected by TLS, or over similar integrity-protected and 


authenticated channels. In addition, when TLS is used, the client 
MUST successfully validate the server’s certificate ([RFC5280], 
[RFC6125]). 
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Note: An Intranet does not constitute such an integrity-protected and 
authenticated channel! 

2. Authentication Flow 


While SAML itself is merely a markup language, its common use case 
these days is with HTTP [RFC2616] or HTTPS [RFC2818] and HTML 


[W3C-REC-HTML401]. What follows is a typical flow: 
1. The browser requests a resource of an RP (via an HTTP request). 
2. The RP redirects the browser via an HTTP redirect (as described 


in Section 10.3 of [RFC2616]) to the IdP or an IdP discovery 
service. When it does so, it includes the following parameters: 
(1) an authentication request that contains the name of the 
resource being requested, (2) a browser cookie, and (3) a return 
URL as specified in Section 3.1 of [OASIS-SAMLv2-PROF]. 


3. The user authenticates to the IdP and perhaps authorizes the 
release of user attributes to the RP. 


4. In its authentication response, the IdP redirects (via an HTTP 
redirect) the browser back to the RP with an authentication 
assertion (stating that the IdP vouches that the subject has 
successfully authenticated), optionally along with some 
additional attributes. 


5. The RP now has sufficient identity information to approve access 
to the resource or not, and acts accordingly. The authentication 
is concluded. 


When considering this flow in the context of SASL, we note that while 
the RP and the client both must change their code to implement this 
SASL mechanism, the IdP can remain untouched. The RP already has 
some sort of session (probably a TCP connection) established with the 
client. However, it may be necessary to redirect a SASL client to 
another application or handler. The steps are as follows: 


1. The SASL server (RP) advertises support for the SASL SAML20 
mechanism to the client. 


2. The client initiates a SASL authentication with SAML20 and sends 


a domain name that allows the SASL server to determine the 
appropriate IdP. 
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3. The SASL server transmits an authentication request encoded using 
a Uniform Resource Identifier (URI) as described in RFC 3986 
[RFC3986] and an HTTP redirect to the IdP corresponding to the 
domain. 


4. The SASL client now sends a response consisting of "=". 
Authentication continues via the normal SAML flow, and the SASL 
server will receive the answer to the challenge out of band from 
the SASL conversation. 


5. At this point, the SASL client MUST construct a URL containing 
the content received in the previous message from the SASL 
server. This URL is transmitted to the IdP either by the SASL 
client application or an appropriate handler, such as a browser. 


6. Next, the user authenticates to the IdP. The manner in which the 
end user is authenticated to the IdP, and any policies 
surrounding such authentication, are out of scope for SAML and 


hence for this document. This step happens out of band from 
SASL. 
7. The IdP will convey information about the success or failure of 


the authentication back to the SASL server (RP) in the form of an 
authentication statement or failure, using an indirect response 
via the client browser or the handler (and with an external 
browser, client control should be passed back to the SASL 
client). This step happens out of band from SASL. 


8. The SASL server sends an appropriate SASL response to the client. 


Please note: What is described here is the case in which the client 
has not previously authenticated. It is possible that the client 
already holds a valid SAML authentication token so that the user does 
not need to be involved in the process anymore, but that would still 
be external to SASL. This is classic Web Single Sign-On, in which 
the Web Browser client presents the authentication token (cookie) to 
the RP without renewed user authentication at the IdP. 
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With all of this in mind, the flow appears as follows in Figure 2: 


SASL Serv. Client IdP 

>----- (1) ----- > | | Advertisement 
| | | 
|<----- (is <| | Initiation 
| | | 
|> erie aes (3) ----- > | | Authentication Request 
ENES Ha penes < | Response of "=" 
| | | 
| |<- -(5,6) - ->| Client<>IdP 
| | | Authentication 
| | | 
|<- ---------- (7)- - -| Authentication Statement 
RESTE (8) ===> > | SASL Completion with 
| | | Status 
| | | 

----- = SASL 


— — — = HTTP or HTTPS (external to SASL) 
Figure 2: Authentication Flow 
3. SAML SASL Mechanism Specification 


This section specifies the details of the SAML SASL mechanism. See 
Section 5 of [RFC4422] for additional details. 


The name of this mechanism is "SAML20". The mechanism is capable of 
transferring an authorization identity (via the "gs2-header"). The 
mechanism does not offer a security layer. 


The mechanism is client-first. The first mechanism message from the 
client to the server is the "initial-response". As described in 
[RFC4422], if the application protocol does not support sending a 
client response together with the authentication request, the server 
will send an empty server challenge to let the client begin. The 
second mechanism message is from the server to the client, containing 
the SAML "authentication-request". The third mechanism message is 
from the client to the server and is the fixed message consisting of 
"=". The fourth mechanism message is from the server to the client, 
indicating the SASL mechanism outcome. 
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3.1. Initial Response 


A client initiates a SAML20 authentication with SASL by sending the 
GS2 header followed by the Identity Provider identifier (message 2 in 
Figure 2) and is defined using ABNF [RFC5234] as follows: 


initial-response = gs2-header IdP-Identifier 
IdP-Identifier = domain ; domain name with corresponding IdP 


The gs2-header is used as follows: 
- The "gs2-nonstd-flag" MUST NOT be present. 


- The "gs2-cb-flag" MUST be set to "n" because channel-binding 
[RFC5056] data cannot be integrity protected by the SAML 
negotiation. (Note: In theory, Channel-binding data could be 
inserted in the SAML flow by the client and verified by the 
server, but that is currently not supported in SAML.) 


- The "gs2-authzid" carries the optional authorization identity as 
specified in [RFC5801] (not to be confused with the 
IdP-Identifier). 


A domain name is either a "traditional domain name" as described in 
[RFC1035] or an "internationalized domain name" as described in 
[RFC5890]. Clients and servers MUST treat the IdP-Identifier as a 
domain name slot [RFC5890]. They also SHOULD support 
internationalized domain names (IDNs) in the IdP-Identifier field; if 
they do so, all of the domain name’s labels MUST be A-labels or 
NR-LDH labels [RFC5890]. If necessary, internationalized labels MUST 
be converted from U-labels to A-labels by using the Punycode encoding 
[RFC3492] for A-labels prior to sending them to the SASL server, as 
described in the protocol specification for Internationalized Domain 
Names in Applications [RFC5891]. 


3.2. Authentication Request 


The SASL server transmits to the SASL client a URI that redirects the 
SAML client to the IdP (corresponding to the domain that the user 
provided), with a SAML authentication request as one of the 
parameters (message 3 in Figure 2) using the following ABNF: 


authentication-request = URI 
The URI is specified in [RFC3986] and is encoded according to 
Section 3.4 ("HTTP Redirect Binding") of the SAML 2.0 bindings 


specification [OASIS-SAMLv2-BIND]. The SAML authentication request 
is encoded according to Section 3.4 ("Authentication Request 
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Protocol") of [OASIS-SAMIv2-CORE]. Should the client support 
Internationalized Resource Identifiers (IRIs) [RFC3987], it MUST 
first map the IRI to a URI before transmitting it to the server, as 
defined in Section 3.1 of [RFC3987]. 


Note: The SASL server may have a static mapping of domain to 
corresponding IdP or, alternatively, a DNS-lookup mechanism could be 
envisioned, but that is out of scope for this document. 


Note: While the SASL client MAY sanity-check the URI it received, 
ultimately it is the SAML IdP that will be validated by the SAML 
client; this topic is out of scope for this document. 


The client then sends the authentication request via an HTTP GET 
(sent over a server-authenticated TLS channel) to the IdP, as if 
redirected to do so from an HTTP server and in accordance with the 
Web Browser SSO profile, as described in Section 4.1 of 
[OASIS-SAMLv2-PROF] (messages 5 and 6 in Figure 2). 


The client handles both user authentication to the IdP and 
confirmation or rejection of the authentication of the RP (out of 
scope for this document). 


After all authentication has been completed by the IdP, the IdP will 
send a redirect message to the client in the form of a URI 
corresponding to the RP as specified in the authentication request 
("AssertionConsumerServiceURL") and with the SAML response as one of 
the parameters (message 7 in Figure 2). 


Please note: This means that the SASL server needs to implement a 
SAML RP. Also, the SASL server needs to correlate the session it has 
with the SASL client with the appropriate SAML authentication result. 
It can do so by comparing the ID of the SAML authentication request 
it has issued with the one it receives in the SAML authentication 
statement. 


3.3. Outcome and Parameters 
The SASL server (in its capacity as a SAML RP) now validates the SAML 


authentication response it received from the SAML client via HTTP or 
HTTPS. 


The outcome of that validation by the SASL server constitutes a SASL 
mechanism outcome and therefore (as stated in [RFC4422]) SHALL be 
used to set state in the server accordingly, and it SHALL be used by 
the server to report that state to the SASL client, as described in 
[RFC4422], Section 3.6 (message 8 in Figure 2). 
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4. 


SAML GSS-API Mechanism Specification 


This section and its sub-sections are not required for SASL 
implementors, but this section MUST be observed to implement the 
GSS-API mechanism discussed below. 


This section specifies a GSS-API mechanism that, when used via the 
GS2 bridge to SASL, behaves like the SASL mechanism defined in this 
document. Thus, it can loosely be said that the SAML SASL mechanism 
is also a GSS-API mechanism. The SAML user takes the role of the 
GSS-API Initiator, and the SAML RP takes the role of the GSS-API 
Acceptor. The SAML IdP does not have a role in GSS-API and is 
considered an internal matter for the SAML mechanism. The messages 
are the same, but 


a) the GS2 header on the client’s first message and channel-binding 
data are excluded when SAML is used as a GSS-API mechanism, and 


b) the initial context token header (Section 3.1 of [RFC2743]) is 
prefixed to the client’s first authentication message (context 
token). 


The GSS-API mechanism OID for SAML is 1.3.6.1.5.5.17 (see Section 7.2 
for more information). The DER encoding of the OID is 
0x2b 0x06 0x01 0x05 0x05 0x11. 


SAML20 security contexts MUST have the mutual_state flag 
(GSS_C_MUTUAL_FLAG) set to TRUE. SAML does not support credential 
delegation; therefore, SAML security contexts MUST have the 
deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE. 


The mutual authentication property of this mechanism relies on 
successfully comparing the TLS server’s identity with the negotiated 
target name. Since the TLS channel is managed by the application 
outside of the GSS-API mechanism, the mechanism itself is unable to 
confirm the name, while the application is able to perform this 
comparison for the mechanism. For this reason, applications MUST 
match the TLS server’s identity with the target name, as discussed in 
[RFC6125]. More precisely, to pass identity validation, the client 
uses the securely negotiated targ_name as the reference identifier 
and matches it to the DNS-ID of the server’s certificate, and it MUST 
reject the connection if there is a mismatch. For compatibility with 
deployed certificate hierarchies, the client MAY also perform a 
comparison with the Common Name ID (CN-ID) when there is no DNS-ID 
present. Wildcard matching is permitted. The targ_name reference 
identifier is a "traditional domain names"; thus, the comparison is 
made using case-insensitive ASCII comparison. 
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4. 


3% 


5. 


The SAML mechanism does not support per-message tokens or the 
GSS_Pseudo_random() function [RFC4401]. 


1. GSS-API Principal Name Types for SAML 


SAML supports standard generic name syntaxes for acceptors such as 
GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1). SAML 
supports only a single name type for initiators: GSS_C_NT_USER_NAME. 
GSS_C_NT_USER_NAME is the default name type for SAML. The query, 
display, and exported name syntaxes for SAML principal names are all 


the same. There are no SAML-specific name syntaxes -- applications 
should use generic GSS-API name types, such as GSS_C_NT_USER_NAME and 
GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743] Section 4). The exported 


name token, of course, conforms to [RFC2743], Section 3.2. 

Examples 
1. XMPP 

Suppose the user has an identity at the SAML IdP saml.example.org and 
a Jabber Identifier (JID) "somenode@example.com" and wishes to 
authenticate his XMPP [RFC6120] connection to xmpp.example.com. The 
authentication on the wire would then look something like the 


following: 


Step 1: Client initiates stream to server: 


<stream:stream xmlns=’ jabber:client’ 
xmlns:stream=’http://etherx. jabber.org/streams’ 
to=’example.com’ version='1.0'> 


Step 2: Server responds with a stream tag sent to client: 


<stream:stream 
xmlns=’' jabber:client’ xmlns:stream=’http://etherx. jabber.org/streams’ 
id=’some_id’ from=’example.com’ version='1.0'> 


Step 3: Server informs client of available authentication mechanisms: 


<stream: features> 

<mechanisms xmlns=’urn:ietf:params:xml:ns:xmpp-sasl’> 
<mechanism>DIGEST-MD5</mechanism> 
<mechanism>PLAIN</mechanism> 
<mechanism>SAML20</mechanism> 

</mechanisms> 

</stream: features> 
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Step 4: Client selects an authentication mechanism and provides the 
initial client response -- containing the gs2-header and domain -- 
that has been encoded in base64 according to Section 4 of [RFC4648]: 


<auth xmlns=’urn:ietf:params:xml:ns:xmpp-sasl’ mechanism=’ SAML20’> 
biwsZXhhbXBsZS5vcmc=</auth> 


The decoded string is 


nN, example.org 


Step 5: Server sends a base64-encoded challenge to client in the form 
of an HTTP redirect to the SAML IdP corresponding to example.org 
(https: //saml.example.org) with the SAML authentication request as 
specified in the redirection URL: 


aHROcHM6Ly9zYW1sLmV4YW1wbGUub3JInL1INBTUwWvOnJvd3N1cj9TOQU1MUMVXx 
AWVzAD1OSE5DOY1d4d09rRjFKR2h1VW1WeGRXVnpkQ0I0Y1d4dAWN6CcHpZVzFzZ 
YOOwaWRYSnVPbTl1oYzJsek9tNwWhiV1Z6T25Sak9sTKIJUVXc2TWk0d09u0nli 
M1J2WTI5cO1lnMEt JQOFNSUVSRVBTSmZZbVZqTKRIMFptRTFNVEF 6TKRINE 9U 
QTVZVE13Wm1ZeFpUTXANVFkOTXpUM1pqy zVORGMwT1RnME1pQldaWEp6YVc5 
AVBTSX1MakFpRFFVZ01DQWdTWE5 6ZFdWSmJuT JBZVZUWUFNJeULEQTNMVEV5 
TFRFd1ZERXhPak0O1T2pNMFdpSWdSbT15WTJWOmRYUm9iajBoWm1Gc2MyVW1E 
UW9INSUNBZINYTIFZWE56YVhabFBTSml1ZV3h6W1NJTKNpOWAJOOJRY205MGIy 
TnZiRUpwYm1ScGJtYz1Jb1Z5Ympwdl1YTnBjenB1WVcxbGN6cDBZenBUUVUX 
TU9SXVNRHBpYVcla2FXNW53jenBJIVkZSUUXWO1BVMVFpREFFvZ0O1DOWdRWE56 
W1hKMGFXOXVRM311YzNWdFpYS1RaWEoyYVdObFZWSk1QUTBLSUNBZO1DOWdAJ 
QOFpPYUHSMGNITTZMeTkOYLACdOxtVIRZVzZF3YkdVdVkyOXRMMUSCVFV3d1FY 
TnpaWEowYVcSdVEyOXVjM1ZOWLAKVFEpYS jJhVO5sSWoOTKNpOTh  jMkZO0YkRw 
SmMzTjFaWE1nZUcxc2JuTTZjMkZ0YkQwaWRYSnVPbDT1oOYzJsek9tNWhiV126 
T25Sak9sTkIUVXc2TWk0d0 9tRnp jM1Z5ZEdsdmJpSStEUW9INSUNBZO01HaDBk 
SEJ6T2k4dmVHMXd jOzVsZUdGdGNHeEGxMbU52Y1EwSO1Ed3ZjMkZOYkRwSmMz 
TjJFaWEkrRFFVZ1IBITmhiV3h3T2slaGJUXVkpSRkJ2YkdsamVTQjJRiIV3h1Y3pw 
ell1XMXN3RDBpZFhKdU9tOWh3jMmx6T201aGJXVnpPb1JqT2x001RVdzZNaTR3 
T25CeWIzUnZZM31zSWcwS01DOWdJOOJHY3NKdF1YUT1Jb1Z5Ympwdl1YTnB3 
enB1WVcxbGN6cDBZenBUUVUXTU9ISXVNRHB1WVcxbGFXUXRabT15Y1dGME 9u 
Qmx jbk 5wY zNSbGJuUWLEUW9InNSUNBZ01GT1LFUbUZOW1LZGMV1XeHBabWxsY2ow 
aWVHMXd30zVs ZUdGAGNHeGxMbU52Y1NJZ1FXeHNiM2REY21WaGRHVT1Jb1J5 
ZFAVaU1DOCtEUW9INUEhOaGJXeHdPLbEpsY1hWbGMzUmxaRUYxZEdodVEyOXVk 
R1YO0ZEEwS01DOWdAJO0TIOY1d4AWN6CHpZVzZFzZYOQOwaWRYSnVPbTloYzJsek9t 
NWhiV1Z6T25Sak9sTkJUVXc2TWkO0d0 9uQn1liM1J2WTI5c01pQU5DaUFnNSUNB 
ZO0O1DOWARM310Y0dGeWFYTnZiajBpWlhoaFkzUW10ZzBLSUNBOGMyRnRiRHBC 
ZFhsb2JrTnZib1JsZUhSRGJHRnp3]MUpsWmcwS01DOWaAJO0FnZUCxc2JuTTZ5 
MkZOYkOwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTKJIUVXc2TWk0Od09t 
RnpjM1Z5ZEdsdmJpSStEUWINDONBZO1DOjF3LTO2Y3jJGemFYTTZibUZOW1hN 
NmRHTTZVMEZOVERVeUxqOTZZV002WTJ4aGMzTmx jenBRWVhOemQyOX1laRkJ5 
Y 3NSbFkzUmxaR1J5WVcl1lemNHOX1kQOTBLSUNBOEwzTmhiV3c2UVhWMGFHNURi 
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MjUwWLhoMFEyeGh jM05TW1dZKORRb2dQ0z1 6WVcxc2NECFNaWEYxWLhOMFpxX 
UKkJkWF JvYmtOdmJuUmx1SFErSUEwS1BDOXpZVzFzYORwOmRYUm9ibEpsY1hW 
bGMzUSs= 


The decoded challenge is as follows: 


https://saml.example.org/SAML/Browser?SAMLRequest =PHNhbWxwOk 
F1dGhuUMVxdWVzaACB4bWxuczpzYW1lscDO0idXJu0m9hc21zOm5hbWVzOnR3O1 
NBTUw6Mi 4wOnByb3RvY29sIg0KICAgIElEPSJIfYmV3NDIOZmE1MTAZNDI4OT 
A5YTMwZmYxZTMxMTY4Mz13Z3jc5NDc0OTgOTiBWZXIJzaW9%uPSIyLjAiDQogIC 
AgSXNzdWVJbnNOYWS5O0PSIyMDA3LTEyYLTEWVDExOjM50jMOWilgRm9yY2VBdxX 
Robj0iZmF'sc2UiDQOogICAgSXNOYXNzaxXZ1PSJmYWxzZSINCiAgICBOcm90b2 
NvbEJpbmRpbmc 9InVybjpvYXNpcezpuYWllczp0YzpTQU1MOjTuMDpiaW5kaw 
5BnczpIVFROLVBPU1QOiDOo0gICAgOXNzZXJI0aW9u029uc3VtZXITZXI2aWwN1VV 
JMPQOKICAgICAgICAiaHROcHM6Ly 94bXBwLmV4YW1wbGUuY29t L1INBTUwvQX 
NzZXJ0aW9u029uc3VEZXITZXI2aWN1134NCiA8c2FtbDpJc3N1ZXIgeGlsbn 
M6c2FtkbD0idXJu0m9hc21zOm5hbWVzOnRjO1NBTUwW6Mi4wOmFzc2VydGlvbi 
I+DQogICAgIGhOdHBz0i8veGlwcC5leGFtcGxlLmNvbQOKIDwvc2FtbDpJc3 
N1ZX1I+DQogPHNhbWxwOk ShbWVJRFBvbG1 jeSB4bWxuczpzYW1lscD0idxXJuOm 
9hc21zOm5hbWVzOnRjO1NBTUwW6Mi 4wOnByb3RvY29sIgO0KICAgICBGb3JtYX 
Q9InVybjpvYXNpczpuYW1llczpO0YzpTQU1MOj TuMDpuYW1lawOt Zm9ybWF0On 
BlcnNpc3RlbnQiDQogICAgGIFNOTmFtZVE1YWxpZmllcj0ieGlwcC5leGFtcG 
xlLmNvbSIgQWxsb3dDcmVhdGU9 InRydWUiIC8+DQogPHNhbWxwOlJlcxV1c3 
R1ZEF1dGhuQ2 9udGV4dAOKICAgICB4bWxuczpzYW1scD0idXJu0m9hc21zOm 
5hbWVzOnRjO1NBTUwW6Mi4wOnByb3RvY29sTiANCiAgICAgICAgQ29%tcGFyaX 
Nvb3j0iZXhhY30iPg0KICA8c2FtbDpBdaXRobkNvbnRl1eHRDEbGFzc1J1Zg0KIC 
AgICAgeG1sbnM6c2FthbD0idXJu0m9hc21zOm5hbWVzOnRJO1NBTUwW6Mi4wOm 
Fzc2VydGlvbiIl+DQogICAgICAgICAgIHVybjpvYXNpczpuYWllczp0YzpTQu 
1M03jIuMDphYzp3jbGFzc2Vz01Bhc3N3b3JkUHIvaGV3jdGVKkVHIhbnNwb3J0DO 
ogIDwvc2FtbDpBdaXRobkNvbnR1eHRDbGFzc1J123]4NCiA8L3NhbWxw01J1cX 
V1c3R1ZEF1dGhuQ2 9udGV4dD4gDOo08L3NhbWxwOkF1dGhuUmVxdWvzdD4= 


Where the decoded SAMLRequest looks like the following: 


<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
ID="_bec424fa5103428909a30ff1e31168327£79474984" Version="2.0" 
Issuelnstant="2007-12-10T11:39:34Z" ForceAuthn="false" 
IsPassive="false" 
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
AssertionConsumerServiceURL= 
"https://xmpp.example.com/SAML/AssertionConsumerService"> 
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> 
https://xmpp.example.com 
</saml:Issuer> 
<samlp:NameIDPolicy xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" 
SPNameQualifier="xmpp.example.com" AllowCreate="true" /> 
<samlp:RequestedAuthnContext 
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xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
Comparison="exact"> 

<saml:AuthnContextClassRef 
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> 
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport 

</saml:AuthnContextClassRef> 

</samlp:RequestedAuthnContext> 
</samlp:AuthnRequest> 


Note: The server can use the request ID 
("_bec424fa5103428909a30ff1le31168327f79474984") to correlate the SASL 
session with the SAML authentication. 


Step 5 (alternative): Server returns error to client if no SAML 
authentication request can be constructed: 


<failure xmlns=’urn:ietf:params:xml:ns:xmpp-sasl’ > 
<temporary-auth-failure/> 

</failure> 

</stream:stream> 


Step 6: Client sends the "=" response (base64-encoded) to the 
challenge: 


<response xmlns=’urn:ietf:params:xml:ns:xmpp-sasl’> 
</response> 


The following steps between brackets are out of scope for this 
document but are included to better illustrate the entire flow: 


[The client now sends the URL to a browser instance for processing. 
The browser engages in a normal SAML authentication flow (external to 
SASL), like redirection to the IdP (https://saml.example.org); the 
user logs into https://saml.example.org and agrees to authenticate to 
xmpp.example.com. A redirect is passed back to the client browser. 
The client browser in turn sends the AuthN response, which contains 
the subject-identifier as an attribute, to the server. If the AuthN 
response doesn't contain the JID, the server maps the subject- 
identifier received from the IdP to a JID.] 


Step 7: Server informs client of successful authentication: 


<success xmlns=’urn:ietf:params:xml:ns:xmpp-sasl’ /> 
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Step 7 (alternative): Server informs client of failed authentication: 


<failure xmlns=’urn:ietf:params:xml:ns:xmpp-sasl’> 
<not-authorized/> 

</failure> 

</stream:stream> 


Please note: Line breaks were added to the base64 data for clarity. 
SRA IMAP 


The following sequence describes an IMAP exchange. Lines beginning 
with 'S:” indicate data sent by the server, and lines starting with 


'C:’ indicate data sent by the client. Long lines are wrapped for 
readability. 

S: * OK IMAP4revl 

€ . CAPABILITY 

S: * CAPABILITY IMAP4revl STARTTLS 

S OK CAPABILITY Completed 

C STARTTLS 

S: . OK Begin TLS negotiation now 

C: . CAPABILITY 

S: * CAPABILITY IMAP4rev1 AUTH=SAML20 

S OK CAPABILITY Completed 

€ . AUTHENTICATE SAML20 

Si + 

C: biwsZXhhbXBsZS5vemc= 

S: + aHROcHM6Ly9zYW1sImV4YW1wbGUub3JnLINBTUwvOnJvd3N1c3j9TQU1M 


UmVxdAWVzdD10SE50Y1d4d09rRgOKMWRHaHVVbVZ4ZFdWemRDOJRiV3h1Y3pwe 
11XMXN3RDBpZFhKdU9tOWh3jMmx6T201aGJXVnpPb1JqT2x00g0KVFV3Nk1pNH 
dPbkJ5YjNSd1LkyOXNJZzBLSUNBZO1FbDEVQUOpmWW1WakSESTBabUUxTVRBek5 
ESTRPVEE1WQOKVE13Wm1ZeFpUTXhANVFkOTXpJM1pgYzVORGMwT1RnME1pQ1da 
WEp6YVc5dVBTSX1MakFpRFFvZ0O1DOWATWAOKTnpkV1ZKYm50MF1XNTBQUO15T 
URBMOXURX1MVEV3VkRFeE9qTTVPak0wV21JZ1Jt0X1ZM1ZCZFhSb2JgaMA0OKaV 
ptRnNjM1IVpPREFFvZ01DOWATWES5RWVhOemFYWmxQU0ptWVd4elpTSUS5DaUFnSUN 
CUWNtOTBiMk52YkVKcA0KYm1ScGJtYz1Jb1Z5Ympwdl1YTnBjenB1WVcxbGN6 
CcDBZenBUUVUXTU9GSXVNRHBpYVcla2FXNW53jenBIVgOKR1IRTFZCUFUXUW1EU 
WINSUNBZ1FYTnpaWEowYVc5dVEyOXV3M1Z0W1hKVFpYS3jJhVO5sV1ZKTVBRME 
tJQw0KQWdJQOFnNSUNBaWF IU jJBISEO2THK5dF1LXbDHNMbVY OWVcxd2JHVXVZMj41 
OTDFOQIRVd3ZRWE5 6WLHKMGFXOQOKAVEyOXV jM1ZOWLAKVFpYS jIJhAVO5sSWo0 
TkNpOTh3]MkZOYkRwSmMzT3]FaWE1nZUcxc2JuTTZ]MKZOYKQwaQ0KZFhKdU9tO 
Wh3jMmx6T201laGJXVnpPb1JgT2x001RVdzZNaTR3T21GemMyVn1kR2x2Ym1JK0O 
RRb2dJO00FNSQOKR2gGwZEhCek9pOHZ1RzZF3YO0M1bGVHRNR3R3hsTG1OdMIRMEt 
JRHd2YzJGdGJEcEp jM04xW1LhHIKORRb2dQSA0KTmhiV3h3T2slaGJUXVkpSRkJ2 
YkdsamVTO3JRiV3h1Y3pwel1XMXN3RDBpZFhKdU9tOWh3jMmx6T201aGJXVg0Ke 
k9uUmpPLbE5CVFV3NkKk1pPNHAPLkI5DYI]NSA1KYyOXNIZZBLSUNBZO1DOKdiMOpOwWV 
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hROULUVnlianB2WVhOcAOKY 3pwdV1XMWxjenAwWXpwVFFVMU1Pak11TURwdvV1 
XMWxhV1FOWm05eWJXRIBPbkIsY250cGMzUmxib1lFpRAOKUW9NSUNBZO1GTI1FU 
bUZOW1LZGMV1XeHBabWxs Y20waWVHMXdj0zVsZUdGdGNHeEGxMbU52Y1INJZ1FXe 
HNiMwOKZERJbVZoZEdVOUluUn1kV1VpSUM4KORRLD2d0SE50Y1d4d09sSmx3WF 
ZsYZNSbFpFRIFKR2Z2hH1UTISdWRHVgOKNGRBMEt JOOFNSUNCNGJXeHV jenB6éwVc 
xC2NEMGLKWEp1T205aGMybHpPbTVoY1dWek 9uUmpPbESCVFV3Ng0KTWk0d09u 
QnliM1J2WTI5c0O1pQU5DaUFNSUNBZ01DQWdRMjJ1OYOdGeWFYTnZiajBpWlhoa 
FkzZzUWLOZzZBLSQOKQOE4YzJGAGJEcEJKWF JvYmt OdmJuUmx1SFJEYkdGemMxSm 
xaZzBLSUNBZ01DQWd1RzFzYm5NNmMyRnRiRAOKMG1LkKWEp1T205aGMybHpPbTV 
oY1dWek 9uUmpPbESCVFV3Nk1pNHdPbUZ6Y zJWeWRHDHZiaUkrRFFVvZ01DQOQOK 
ZO1LDQJF JbTO2ZY jIGemF YTTZibUZOWLHNNmRHTTZVMEZOVERVeUxgqQTZZV002W 
TJ4aGMzTmx jenBRWVhOegO0KZDI5eVpGOnliM1JsWINSbFpGUn1ZVzvV6Y0c5ewW 
RBMEt JQOE4 TDNOaGJXdzZRWE YwYUc1RGI yNTBaWGgwUQO0KMnhoY zNOU1pxXWSt 
EUW9NUEM5el1XMXN3JRHBTW1hGMVpYT3jBaV1JCZFhSb2JrTnZiblJsZUhRKO1B 
MEt QQw0KOXpZVzFzYORwOmRYUm9ibEpsY 1hWbGMzUSs= 

C: PQ== 

S: . OK Success (TLS protection) 


The decoded challenge is as follows: 


https: //saml.example.org/SAML/Browser?SAMLRequest=PHNhbWxwOkF 
1dGhuUmVxdWVzdCB4bWxuczpzYW1scD0idXJu0m9hc21zOm5hbWVzOnR3jO1NB 
TUw6Mi 4wOnByb3RvY29sIg0KICAgIElEPSJfYmV3NDIOZmE1MTAZNDI4OTADY 
TMwZmYxZTMxMTY4Mz13ZjcSNDcOOTgOIiBWZXJzaW9uPSTyLJAiDQogICAgSxX 
NzdWVJbnNOYW50PSIyMDA3LTEyYLTEWVDEx0O  jM50jMOWilgRm9yY2VBdXRobj0 
iZmFsc2UiDOO0gICAgSXNOYXNzaXZ1PSJmYWxzZSINCiAgICBOcm90b2NvbEJp 
bmRpbmc 9InNVybjpvYXNpczpuYwWwl1czpO0YzpTOQU1MOJIuMDpiaW5kaW5nczpIV 
FROLVBPU1QiDOO0gICAgOXNzZZXJ0aW9%uQ029uc3VtZXJITZXI2aWN1VVIMPQOKIC 
AgICAgICAiaHROcHM6Ly 9t YW1sLmV4YW1wbGUuY2 9t LINBTUWVOXNzZXJ0aw9 
uQ2 9uc3VtZXITZXIZaWN1IJ4NCiA8c2FtbDpJc3N1ZXIgeGlsbnM6c2FtbD0i 
daxXJu0m9hc21zOm5hbWVzOnRJO1NBTUw6Mi4wOmFzc2VydGl1vbil+DO0ogICAgl 
GhOdHBz0i8veGlwcC5leGFtcGx1lLmNvbQOKIDwvc2FtbDpJc3N12ZXI+DQo0gPH 
NhbWxwOk5hbWVJRFBvbG1 jeSB4bWxuczpzYW1lscD0idxJuOm9hc21zOm5hbwv 
zOnRJOLNBTUW6Mi 4wOnByb3RvY2 9s IgOKICAgICBGb3JUt YXQO9InVyb jpvYXNp 
czpuYWllczp0YzpTQU1MOj TuMDpuYW1lawOt Zm9ybWF O0OnBlcnNpc3R1lbnQiD 
QogICAgIFNOTMFtZVF1YWxpZmllcj0ieGlwcC5leGFtcGx1lLmNvbSIgQWxsb3 
dDcmVhdGUITnRydWUiIC8+DOQogPHNhbWxwOlJ1lcXV1c3R1ZEF1dGhuQ2 9udGV 
4dAO0KICAgICB4bWxuczpzYW1scD0idXJu0m9hc21zOm5hbWVzOnRjO1NBTUwW6 
Mi4wOnByb3RvY29sIiANCiAgICAgICAgQ29tcGFyaXNvb3j0iZXhhY30iPg0KI 
CA8c2FtbDpBdXRobkNvbnR1eHRDbGF zclJlZgOKICAgICAgeGlsbnM6c2FtbD 
0idXJu0m9hc21zOm5hbWVzOnRjO1NBTUw6Mi 4wOmF zc2VydGlvbilI+DQogICA 
gICB1cm46b2FzaXM6bmFtZXM6dGME6UOENTDOyLjAG6YWM6Y2xhc3N1czpQYXNz 
d29yZFByb3R1Y3R1ZFRyYW5zcG9ydAOKICA8L3NhbWw60XV0aG5Db250ZXh00 
2xhc3NSZWY+DQOogPC9zYW1scDpsZXF1ZXNOZWRBdXRobkNvbnRl1eHO+TAOKPC 
9ZYW1scDpBdXRob1J1cXV1c3Q+ 
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Where the decoded SAMLRequest looks like the following: 


<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
ID="_bec424fa5103428909a30ff1e31168327£79474984" Version="2.0" 
Issuelnstant="2007-12-10T11:39:34Z" ForceAuthn="false" 
IsPassive="false" 
ProtocolBinding="urn:o0asis:names:tc:SAML:2.0:bindings:HTTP-POST" 
AssertionConsumerServiceURL= 
"https://mail.example.com/SAML/AssertionConsumerService"> 
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> 
https://xmpp.example.com 
</saml:Issuer> 
<samlp:NameIDPolicy xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" 
SPNameQualifier="xmpp.example.com" AllowCreate="true" /> 
<samlp:RequestedAuthnContext 
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
Comparison="exact"> 
<saml:AuthnContextClassRef 
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> 
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport 
</saml:AuthnContextClassRef> 
</samlp:RequestedAuthnContext> 
</samlp:AuthnRequest> 


6. Security Considerations 


This section addresses only security considerations associated with 
the use of SAML with SASL applications. For considerations relating 
to SAML in general, and for general SASL security considerations, the 
reader is referred to the SAML specifications and to other 
literature. 


6.1. Man-in-the-Middle and Tunneling Attacks 


This mechanism is vulnerable to man-in-the-middle and tunneling 
attacks unless a client always verifies the server’s identity before 
proceeding with authentication (see [RFC6125]). Typically, TLS is 
used to provide a secure channel with server authentication. 


6.2. Binding SAML Subject Identifiers to Authorization Identities 
As specified in [RFC4422], the server is responsible for binding 
credentials to a specific authorization identity. It is therefore 


necessary that only specific trusted IdPs be allowed. This is a 
typical part of SAML trust establishment between RPs and the IdP. 
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6. 


6. 


7. 


7. 


Sia 


Ae 


Ja 


¡Be 


User Privacy 

The IdP is aware of each RP that a user logs into. There is nothing 
in the protocol to hide this information from the IdP. It is not a 
requirement to track the visits, but there is nothing that prohibits 
the collection of information. SASL server implementers should be 


aware that SAML IdPs will be able to track -- to some extent -- user 
access to their services. 


Collusion between RPs 
It is possible for RPs to link data that they have collected on the 
users. By using the same identifier to log into every RP, collusion 
between RPs is possible. In SAML, targeted identity was introduced. 
Targeted identity allows the IdP to transform the identifier the user 
typed in to an RP-specific opaque identifier. This way, the RP would 
never see the actual user identifier but instead would see a randomly 
generated identifier. 
Security Considerations Specific to GSS-API 
Security issues inherent in GSS-API [RFC2743] and GS2 [RFC5801] apply 
to the SAML GSS-API mechanism defined in this document. Further, and 
as discussed in Section 4, proper TLS server identity verification is 
critical to the security of the mechanism. 
IANA Considerations 

IANA Mech-Profile 
The IANA has registered the following SASL profile: 
SASL mechanism profile: SAML20 
Security Considerations: See this document 
Published Specification: See this document 
For further information: Contact the authors of this document. 
Owner/Change controller: the IETF 


Intended usage: COMMON 


Note: None 
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7.2. IANA OID 


The IANA has also assigned a new entry for this GSS mechanism in the 
SMI Security for Mechanism Codes sub-registry, whose prefix is 
iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5), and 
referenced this specification in the registry. 
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